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(54) System and method for dynamic codec alteration 

(57) A bandwidth adjustment server, BWAS 109 is 
provided which monitors system bandwidth usage, 
sends requests to terminals 102 A, 102B and/or 106, to 
identify their coding capabilities, and directs each of the 
terminals to adjust their coding algorithms based on 
system bandwidth usage. H system bandwidth usage is 
high, the BWAS 109 requires the terminals to employ a 
less bandwidth intensive coding algorithm; similarly, 
when system bandwidth usage is low, the BWAS 109 
will allow the terminals to employ higher bandwidth use 
coding algorithms. Codec renegotiation may be initiated 
if there is a disparity between the bandwidth allocated to 
new connections versus ongoing connections or an 
increase in data traffic. 
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Description 

[0001] The present invention relates to telecommu- 
nications systems, and in particular, to an improved 
telephony-over-LAN (local area network) or other 
packet switched network system. 
[0002] Modern telephony-over-LAN (ToL) systems 
allow each endpoint (e.g., client, gateway) to choose a 
default hierarchy of coding algorithms. For example, an 
endpoint might be configured to first try using adaptive 
pulse code modulation (AD PCM), next G.723, then 
GSM, etc., until a common codec supported by both the 
calling and called endpoints is found. 
[0003] However, the endpoints or clients typically 
have static configurations of preferred codecs. As a 
consequence, network bandwidth is assigned on a sim- 
ple availability basis, without regard to other users who 
might wish to place phone calls in the future. As a con- 
sequence, a few users who communicate using coding 
algorithms that result in high bandwidth consumption 
could use the entire network bandwidth, without even 
realizing bandwidth was in short supply, thereby pre- 
venting others from placing calls. As such, system 
bandwidth may be inefficiently utilized and even result in 
denial of service to some users. Moreover, subsequent 
callers with a higher QoS (quality of service) require- 
ment may be forced to use a less optimal codec while a 
preceding call with a low QoS communicates using its 
desired codec. 

[0004] While certain data modems, as described in 
U.S. Patent No. 5,546,395, allow tor dynamic bandwidth 
adjustment between two communicating endpoints, by 
way of selecting the compression rates for voice trans- 
mission and the modulation rate, such systems do not 
allow for broad network-based supervision of bandwidth 
allocation. 

[0005] These and other drawbacks in the prior art 
may be overcome in large part by a coding algorithm 
policy adjustment system according to embodiments of 
the present invention. 

[0006] The invention is defined in the independent 
claims, to which reference should now be made. Further 
advantageous features are detailed in the dependent 
claims. 

[0007] In one embodiment, a telecommunications 
system comprises a packet switched network; one or 
more telephony devices coupled to said packet 
switched network, at least one of the telephony devices 
configured to communicate using more than one coding 
algorithms; and a bandwidth allocation server config- 
ured to cause a renegotiation of which of said coding 
algorithms said one or more telephony devices commu- 
nicates with, while said one or more telephony devices 
are communicating using a predetermined coding algo- 
rithm. 

[0008] Thus codec (or codec speed) may be rene- 
gotiated for ongoing calls. This may be, for example, 
according to selection criteria that identify which end 



points (or devices) have their codecs renegotiated. 
Selection criteria may be based, for example, on QoS 
and current bandwidth allocation, or whether the call is 
internal or external, or other predetermined criteria. For 

5 example, as will be discussed in greater detail below, a 
number of existing calls may be associated with a 
medium QoS level; that is, a high QoS level is not 
required. The subsequent call may be associated with a 
high QoS, i.e., it is important that the connection is of 

10 high quality. The method and the system may therefore 
include determining whether an existing connection has 
a lower quality of service (QoS) requirement than 
another connection, and changing said codec speed for 
said existing connection responsive to a positive deter- 

15 mination. For example, if the difference between the 
QoS levels meets a threshold, then the existing call(s) 
will have its (or their) codecs renegotiated to a lower 
level. If codecs have already been renegotiated lower 
once, then the BWAS monitors whether they should be 

20 renegotiated still lower, or whether they can be restored 
to their original levels. 

[0009] The system and method may therefore 
select which active terminals (connections) have their 
codecs renegotiated. This may be according to whether 

25 their QoS levels can be altered; preferably according to 
whether their QoS level is currently higher than the 
required QoS or has lower QoS than a requested con- 
nection. Alternatively this function may be carried out by 
one or more of the devices. 

30 [0010] A method, preferably for operating the sys- 
tem as defined, may comprise monitoring network 
usage; and changing codec speed for one or more 
ongoing connections based on said monitoring of the 
network usage. 

35 [0011] The bandwidth adjustment server or band- 
width allocation server (BWAS) may also monitor sys- 
tem bandwidth usage, send requests to user terminals 
to identify their coding capabilities, and or direct each of 
the (or selected) user terminals to adjust their coding 

40 algorithms based on system bandwidth usage and 
optionally also based on selection criteria as described 
above. If system bandwidth usage is high, the BWAS 
requires the user terminals to employ a less bandwidth- 
intense coding algorithm; similarly, when system band- 

45 width usage is low, the BWAS will allow the user termi- 
nals to employ higher bandwidth-use coding algorithms. 
[0012] The BWAS is preferably configured with a 
first threshold identified as the threshold for reducing 
the coder/decoder (codec) speeds of the idle endpoints. 

so The BWAS may monitor system traffic, or communicate 
with other system monitors to determine system band- 
width usage. The BWAS preferably then sends a mes- 
sage to the user terminals, requiring them to identify 
their coding capabilities, the specific hierarchy used by 

55 them and preferably data for the selection criteria. Once 
this information is returned to the BWAS, the BWAS 
may send another message requiring the user terminals 
to lower their bandwidth usage by selecting a lower 
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speed codec. When network traffic drops below a sec- 
ond pre-cortfigured threshold, the BWAS may send 
another message allowing the user terminals to restore 
their original codec choices. 

[0013] The BWAS according to one embodiment 
monitors bandwidth usage, and if there is a disparity 
between the bandwidth allocated to new connections 
versus ongoing ones or an increase in data traffic, the 
BWAS sends a Lower Codec Speed message to all 
active H.323 entities. This causes the H.323 entities to 
renegotiate their codecs. The original calling party may 
then select a lower speed codec and sends a message 
to the called party to proceed with H.323 codec negoti- 
ation. 

[0014] A better understanding of the invention is 
obtained when the following detailed description of 
embodiments thereof, is considered in conjunction with 
the following drawings showing the embodiments, in 
which: 

FIG. 1 is a diagram illustrating a telecommunica- 
tions system according to an embodiment of the 
invention; 

FIG. 2 is a diagram of an exemplary H.323 interface 
according to an embodiment of the invention; 
FIG. 3 is a diagram illustrating an exemplary band- 
width allocation server (BWAS) according to an 
embodiment of the invention; 
FIG. 4 is a flowchart illustrating operation of an 
embodiment of the invention; 
FIG. 5 is a flowchart illustrating operation of another 
embodiment of the invention; 
FIG. 6 is a flowchart illustrating communication 
employing an embodiment of the invention; 
FIG. 7 is a flowchart illustrating operation of an 
embodiment of the invention; 
FIG. 8 is a flowchart illustrating bandwidth monitor- 
ing according to another embodiment of the inven- 
tion; 

FIG. 9 is a flowchart illustrating operation of an 
embodiment of the invention; and 
FIG. 10 is a flowchart illustrating operation of 
another embodiment of the invention. 

[0015] FIG. 1 is a diagram illustrating a telecommu- 
nications system 100 according to an embodiment of 
the present invention. In particular, the telecommunica- 
tions system 1 00 includes a local area network (LAN) or 
packet network 101. Coupled to the LAN 101 may be a 
variety of H.323 terminals 102A, 102B, a multi-point 
control unit (MCU) 104, an H.323 gateway 106, an 
H.323 gatekeeper 108, a LAN server 1 12 and a plurality 
of other devices such as personal computers (not 
shown). The H.323 terminals 102A, 102B are in compli- 
ance with the H.323 standard. Thus, the H.323 termi- 
nals 102A, 102B support H.245 for negotiation of 
channel usage, Q.931 for call signaling and call setup, 
registration admission status (RAS), and RTP/RTCP for 



sequencing audio and video packets. The H.323 termi- 
nals 102 A, 102B may further implement audio and 
video codecs, T.120 data conferencing protocols and 
MCU capabilities. Further details concerning the Rec- 

5 ommendation H.323 may be obtained from the Interna- 
tional Telecommunications Union (ITU). In addition, the 
gatekeeper 108 has coupled thereto a bandwidth allo- 
cation server (BWAS) 109 according to a specific 
embodiment of the invention. As will be discussed in 

to greater detail below, the BWAS 109 monitors system 
bandwidth usage and directs each H.323 terminal to 
adopt a particular codec or coding algorithm according 
to bandwidth availability. It is noted that in other specific 
embodiments the BWAS functionality may also be 

75 incorporated into the gatekeeper 109, placed on any 
terminal or server, or embodied as a separate unit sep- 
arately coupled to the network 101, as long as the 
BWAS can communicate with the endpoints. Thus, the 
figures are merely exemplary. 

20 [0016] A logical diagram of an H.323 interface to 
LAN 101 is shown in FIG. 2, according to an embodi- 
ment of the present invention. The interface includes a 
known network terminal/device 10 utilizing the ITU-T 
H.323 protocol, and a packet network interface 13 that 

25 is coupled to network terminal 10. Network interface 13 
couples the H.323 device to LAN 101. H.323 termi- 
nals/devices and equipment carry real-time voice, video 
and/or data. It should be noted that H.323 is an umbrella 
recommendation that sets standards for multimedia 

30 communications, including telephony-over-LAN com- 
munications. The network can include packet-switched 
Transmission Control Protocol/Internet Protocol 
(TCP/IP) and Internet Packet Exchange (IPX) over 
Ethernet, Fast Ethernet and Token Ring networks. 

35 [0017] The network terminal 10 is coupled to a 
video input/output (I/O) interface 28, an audio I/O inter- 
face 12, a user application interface 19. and a system 
control user interface (SCUI) 20. Network terminal 10 
also includes an H.225 layer 24, a video coder/decoder 

40 (codec) 1 5, an audio codec 1 4, H.245 protocol function- 
ality 18, Q.931 protocol functionality 16, and RAS proto- 
col functionality 32. 

[0018] As seen in FIG. 2, the video I/O interface 28 
which may be part of the standard H.323 device con- 

45 nects to the video codec 22 such as an H.261 codec for 
encoding and decoding video signals. Coupled between 
video I/O interface 28 and H.225 layer 24, video codec 
22 translates encoded video signals to H.225 protocol 
signals. Although the H.261 codec can be the video 

so codec used for an H.323 terminal, other video codecs, 
such as H.263 codecs and others, may also be used for 
encoding and decoding video. The H.245 protocol is 
used to exchange terminal capability information such 
as the video coding algorithm. Generally, the called ter- 

55 minal specifies its capabilities to the calling terminal. 
[0019] Audio I/O interface 12, which may be part of 
a standard H.323 terminal, connects to the audio codec 
14, such as a G.71 1 codec, for encoding and decoding 
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audio signals. Coupled to audio I/O interface 12, audio 
codec 14 is coupled to H.225 layer 24 and translates 
audio signals to H.225 protocol signals. Although the 
G.71 1 codec is the mandatory audio codec for an H.323 
terminal, other audio codecs, such as G.728, G.729, 

G. 723.1. G.722, MPEG1 audio, etc. may also be used 
for encoding and decoding speech, in accordance with 
the present invention. G.723.1 typically is a preferred 
codec because of its reasonably low bit rate, which ena- 
bles preservation of link bandwidth, particularly in 
slower speed network connections. As is known, when 
communicating, H.323 terminals use a common coding 
algorithm or codec supported by all entities to the con- 
versation/conference. This information is exchanged 
during an H.245 capability exchange phase. 

[0020] The control layer 11 interfaced with SCUI 
(system control user interface) 20 provides signaling 
and flow control for proper operation of the H.323 termi- 
nal. In particular, ail non-audio and non-video control 
signaling is handled via SCUI 20. Coupled to SCUI 20 in 
the control layer 11 are H.245 layer 18, Q.931 layer 16 
and RAS layer 17, which couple to H.225 layer 24. 
Thus, SCUI 20 interfaces to the H.245 standard which is 
the media control protocol that allows capability 
exchange, channel negotiation, switching of media 
modes and other miscellaneous commands and indica- 
tions for multimedia communications. SCUI 20 also 
interfaces to the Q.931 protocol which defines the 
setup, teardown, and control of H.323 communication 
sessions. SCUI 20 further interfaces to the Registration, 
Admission, Status (RAS) protocol that defines how 

H. 323 entities can access H.323 gatekeepers to per- 
form among other things address translation, thereby 
allowing H.323 endpoints to locate other H.323 end- 
points via an H.323 gatekeeper. The H.225 standard 
layer 24, which is derived from the Q.931 standard, is 
the protocol for establishing connection between two or 
more H.323 terminals and also formats the transmitted 
video, audio, data and control streams into messages 
for output to the network interface 13 (e.g., transport 
over IP network 101). The H.225 layer 24 also retrieves 
the received video, audio, data and control streams from 
messages that have been input from network interlace 
50. 

[0021] In addition, in accordance with the present 
invention, the H.323 terminals control layer 1 1 may also 
include a coding resources unit 1 1 1 which is used to 
communicate coding resources to the bandwidth alloca- 
tion server (BWAS), as will be described further below. 
User application interface 19, which may be a T. 1 20 pro- 
tocol interface as well as other types of protocol inter- 
faces, also is coupled between H.225 layer 24 and a 
user device 21, which may be for example data equip- 
ment. Thus, an H.323 network may be configured to 
include several different devices. For example, the net- 
work may include a terminal for enabling users con- 
nected to a LAN to speak, a terminal (i.e., gateway) for 
enabling a caller resident on the LAN to call a second 



user through the public switched network, and/or a ter- 
minal for enabling the adapter to communicate through 
a wireless trunk, using a wireless telephone. The device 
may also implement supplementary services according 

5 to the H.450 protocol specification. 

[0022] The H.323 gateway 106 (FIG. 1) generally 
provides a translation function between H.323 confer- 
encing endpoints and other terminal types and performs 
call setup and clearing on both the LAN side and 

10 switched circuit network (e.g., public switched tele- 
phone network or PSTN) side. The H.323 gatekeeper 
108 performs address translation from LAN aliases for 
terminals and gateways to IP or IPX addresses (as 
defined in the RAS specification) as well as bandwidth 

15 management (also specified within the RAS specifica- 
tion). The H.323 gatekeeper 108 may further be used 
for call routing. Further, according to a specific embodi- 
ment of the present invention, the gatekeeper 108 may 
include BWAS 109 which is used to specify coding algo- 

20 rithms (e.g., aucfio, video and/or both) which may be 
used by particular H.323 terminals, based on available 
system bandwidth. The BWAS 109 communicates the 
required coding algorithm to the H.323 terminals using 
RAS messaging. The H.323 terminals then use stand- 

25 ard H.245 signaling to negotiate coding capabilities 
among themselves. It is noted that, while described pri- 
marily with regard to audio coding, the present invention 
is equally applicable to video coding as well. 
[0023] More particularly, an exemplary BWAS 109 

30 is illustrated in FIG. 3. The BWAS 109 includes a net- 
work interface 304 (which may simply be part of the 
standard gatekeeper interface in some embodiments) 
which allows for communication to and from the network 
terminals. In particular, RAS messaging may be 

35 employed by BWAS 109 to control bandwidth usage by 
defining the codecs that may be used by the idle H.323 
terminals. 

[0024] A bandwidth monitor 306 and a control proc- 
essor 302 are coupled to the network interface 304. The 

40 bandwidth monitor 306 monitors bandwidth usage, for 
example, by counting the number of active calls being 
processed by the gatekeeper or by other known meth- 
ods, e.g., monitoring bit rates. The control processor 
302 is coupled to a memory 308 which is used to store 

45 bandwidth threshold information, for example in the 
form of look-up tables. The memory 308 may also be 
used to store information concerning the coding capa- 
bilities of each of the H.323 terminals. In the discussion 
below, "H.323 terminals" may be any H.323 endpoint 

so such as an H.323 client or an H.323 connection in gate- 
way 106. The control processor 302 supervises coding 
request transmissions, reception of the coding informa- 
tion, and determination of whether a coding adjustment 
is necessary. In specific embodiments, the BWAS 109 

55 continuously monitors traffic on the local segment to 
determine whether traffic has crossed any thresholds, 
and BWAS 1 09 may communicate with other monitoring 
agents located on other segments to determine their 
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bandwidth usage. Therefore, BWAS 109 can measure 
and track the network traffic to make the determinations 
of the relevant thresholds being crossed, as discussed 
below. In other embodiments, the BWAS 109 also main- 
tains a database of ongoing calls, their bandwidth 
usage, and their QoS (quality of service) requirements. 
In particular, the BWAS 109 is dynamically aware of 
whether ongoing calls are at or below their requested 
QoS. If one or more new calls require a higher QoS (i.e., 
bandwidth), then the BWAS 109 determines whether 
lower QoS calls may be reset to a still lower QoS codec, 
as will be discussed below. 

[0025] As an example, a flowchart illustrating oper- 
ation of one embodiment of the invention is shown in 
FIG. 4. In step 402, the bandwidth allocation server 
(BWAS) 109 receives configuration information con- 
cerning the bandwidth threshold X, which is the thresh- 
old that must be met before reducing codec speeds. 
The threshold X, typically measured in Megabits per 
second (Mbps), is stored in the memory 308. In step 
404, the BWAS 109 similarly receives configuration 
information concerning the threshold Y, which is the 
threshold that must be met before restoring coding algo- 
rithm choices. The threshold Y is also stored in the 
memory 308. Of course, the order of receiving thresh- 
olds X and Y may be reversed. 
[0026] Next, in step 406. the BWAS 109 sends a 
request message to the H.323 terminals, requesting 
that they return an indication of their available coding 
algorithms and hierarchies. According to one embodi- 
ment, the request is in the form of an RAS message. 
The request message is received at the H.323 terminals 
in their coding resource units 1 1 1 (see FIG. 2). The ter- 
minals' coding resource units 1 1 1 access this informa- 
tion, in a manner similar to that in which the terminals 
access coding information prior to beginning communi- 
cation with another endpoint. The information is then 
transferred to the BWAS 109, either in the form of an 
RAS message or by using H.245 signaling. 
[0027] In step 408, the coding algorithms/hierarchy 
information is received by the BWAS 109 via the net- 
work interlace 304 and stored by the processor 302 in 
the memory 308. Next, in step 410, the BWAS 109, in 
particular the bandwidth monitor 306, proceeds to mon- 
itor system bandwidth usage. A signal representative of 
system bandwidth usage is provided to the processor 
302, which accesses the memory 308 for the threshold 
value X. The processor compares the system band- 
width usage against the threshold value X, and deter- 
mines, in step 412. whether system bandwidth usage 
has exceeded the threshold X. If not, the bandwidth 
monitor 306 continues to monitor bandwidth usage 
(return to step 410). However, if bandwidth usage is 
determined to exceed the threshold X, then in step 414, 
the BWAS 109 sends a command to the H.323 termi- 
nals ordering them to adjust their coding hierarchies so 
that a lower speed codec is employed (the adjustment 
can be either stepping down to the next fastest allowed 



coding algorithm or alternatively stepping down directly 
to a selected algorithm, e.g., the slowest coding algo- 
rithm). Again, this may take the form of an RAS mes- 
sage or H.245 signaling. Each H.323 terminal's coding 
5 resource unit 1 1 1 then adjusts the hierarchy so that the 
higher-speed, more bandwidth-intense coding algo- 
rithms are not employed. 

[0028] The determination of how far to lower the 
bandwidth in step 41 4 may be based on a variety of fac- 

10 tors, including load, traffic expectations, and the like. It 
being understood that any of a variety of methods may 
be employed, an exemplary method is described as fol- 
lows. The BWAS 109 calculates the remaining network 
bandwidth divided by the number of idle users to obtain 

75 a demand, D, which is the demand allocable to each of 
the users if it placed a call. The demand, D, is then mod- 
ified by two pre-conf igured factors which are stored in 
the memory 308. The first factor is the percentage of 
voice load allowed (VLA), representative of, for exam- 

20 pie, the percentage of bandwidth remaining after data 
usage is determined. Thus, if data calls are allowed 
60% of network bandwidth, then VLA = 40%. The sec- 
ond factor is the percentage of calls expected to be acti- 
vated (EA). For example, if there are 100 terminals, and 

25 only half are expected to be active at any time, then EA 
= 50%. A modified demand (MD) is then calculated 
according to the following formula: MD = (D * VLAJ/EA . 
For example, if the threshold X were to be exceeded 
such that 1 Mbps network bandwidth is remaining, and 

30 50 idle users were present, then D would be 1 Mbps/50 
users = 20 kilobits per second (kbps)/user. The modified 
demand (MD) would then be (20 kbps/user * 40 %)/50% 
= 16 kbps/user. 

[0029] Based on the modified demand (MD), the 

35 BWAS 1 09 determines that the first coding algorithm in 
each H.323 terminal's hierarchy that is lower than MD 
should be selected. In the example above, the first cod- 
ing algorithm that is 16 kbps or lower should be 
selected. If the terminal does not have such a coding 

40 algorithm, the next lowest is to be employed (alterna- 
tively, the lowest coding algorithm is to be employed). 
Each H.323 terminal is provided with a message from 
BWAS 109 directing it to reset its coding algorithm to 
the appropriate coding algorithm. 

45 [0030] Returning to FIG. 4, the BWAS 109 contin- 
ues in step 416 to monitor system bandwidth usage. 
Again, the bandwidth monitor 306 provides a signal to 
the processor 302 indicative of system bandwidth 
usage. In response, the processor 302 accesses the 

so memory 308 for the threshold Y. As discussed above, 
the threshold Y is the bandwidth usage threshold below 
which the default hierarchy of coding algorithms may be 
employed. The processor 302 then compares the band- 
width usage provided from the bandwidth monitor 306 

55 with the threshold Y, in step 418. If usage has not fallen 
below the threshold Y, then the bandwidth monitor con- 
tinues to monitor bandwidth usage (return to step 416). 
If, however, the bandwidth usage has fallen below the 
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threshold Y, then in step 420, the BWAS 109 sends a 
message to each of the H.323 terminals directing them 
to restore their predetermined choice of coding algo- 
rithms or, alternatively, a BWAS-specified coding algo- 
rithm (for example, the re-adjustment can be stepping 5 
up to the next fastest coding algorithm or alternatively 
stepping up directly to a selected algorithm, e.g., the 
fastest coding algorithm). Each terminal's coding 
resource unit 1 1 1 then re-adjusts the coding algorithm 
hierarchy accordingly. 

[0031] An alternative embodiment of a method for 
adjusting bandwidth according to the present invention 
is described with reference to FIG. 5. In particular, FIG. 
5 is a flowchart illustrating a method in which coding 
algorithm information is not required by the BWAS 109. 
Instead, the BWAS 109 simply monitors bandwidth 
usage and orders each H.323 terminal to adjust to 
slower coding algorithms according to a fixed, predeter- 
mined schedule along the algorithm hierarchy. 
[0032] In step 502, the bandwidth allocation server 
(BWAS) 109 receives configuration information con- 
cerning the bandwidth threshold X, which is the thresh- 
old that must be met before reducing codec speeds. 
The threshold X, typically measured in Mbps, is stored 
in the memory 308. In a step 504, the BWAS 109 simi- 
larly receives configuration information concerning the 
threshold Y, which is the threshold that must be met 
before restoring coding algorithm choices. The thresh- 
old Y is also stored in the memory 308. Of course, the 
order of receiving thresholds X and Y is not important. 
[0033] Next, in step 506, the BWAS 109, more par- 
ticularly the bandwidth monitor 306, monitors the sys- 
tem bandwidth usage. Again, a signal representative of 
system bandwidth usage is provided to the control proc- 
essor 302, which accesses the memory 308 for the 
threshold value X. The processor compares the system 
bandwidth usage against the threshold value X, and 
determines in step 508 whether system bandwidth 
usage has exceeded the threshold X. If not, the band- 
width monitor 306 continues to monitor bandwidth 
usage (return to step 506). However, if bandwidth usage 
is determined to exceed the threshold X, then in step 
510 the BWAS 109 sends a command to the H.323 ter- 
minals ordering them to adjust their coding hierarchies 
(the adjustment being either stepping down to the next 
fastest coding algorithm or alternatively stepping down 
directly to a selected algorithm, e.g., their slowest cod- 
ing algorithms). Each H.323 terminal's coding resource 
unit 1 1 1 then adjusts the hierarchy so that the higher- 
speed, more bandwidth-intense coding algorithms are 
not employed. 

[0034] According to this embodiment, the selection 
in step 510 of the slower coding algorithm is done on a 
predetermined basis. For example, the BWAS 109 may 
send an RAS command or H.245 signaling to the H.323 
terminals to step down to the next fastest coding algo- 
rithm. Alternatively, the BWAS 109 may command the 
H.323 terminals to step down directly to their slowest 



coding algorithms. The coding resource unit 111 of 
each of the H.323 terminals receives the message and 
adjusts its terminal's coding hierarchy. 
[0035] Once the H.323 terminals have re-set their 
default choices for coding algorithms, the bandwidth 
monitor 306 continues to monitor bandwidth usage, in 
step 512. The bandwidth monitor 306 provides a signal 
indicative of bandwidth usage to the processor 302. The 
processor 302, in turn, accesses the memory 308 for 
the threshold value Y. The processor then performs a 
compare operation, comparing the threshold value Y 
with the bandwidth signal received from the bandwidth 
monitor 306, in step 51 4. If the bandwidth usage level is 
above or equal to Y, then the system continues to mon- 
itor usage (return to step 512). If, however, bandwidth 
usage levels drop below the threshold value Y, then the 
processor 302 issues a command onto the network 
allowing the H.323 terminals to re-adjust their coding 
algorithm hierarchies. Again, this may take the form of 
an RAS message or H.245 signaling, with the readjust- 
ment being either stepping up to the next fastest coding 
algorithm or alternatively stepping up directly to a 
selected algorithm, e.g., the fastest coding algorithm. 
Each H.323 terminal's coding resource unit 111 then 
adjusts accordingly the coding hierarchy so that the 
higher-speed, more bandwidth-intense coding algo- 
rithms are allowed to be employed. 
[0036] In the various specific embodiments of the 
present invention discussed above, the bandwidth can 
thus be continuously monitored for changes in network 
traffic such that dynamic adjustment of the coding algo- 
rithms is accomplished. 

[0037] In the above embodiments, once the H.323 
terminals receive their new coding hierarchies, calls are 
processed in the standard fashion. Thus, for example, 
turning now to FIG. 6, a flowchart illustrating call setup 
employing a coding hierarchy adjustment system 
according to the invention is shown. In particular, in step 
602, a calling H.323 terminal issues an Admission 
Request (ARQ) message to the gatekeeper 108. in step 
604, the gatekeeper 108 accepts by issuing an Admis- 
sion Confirm (ACF) message (it is noted that the gate- 
keeper 108 could reject by responding with an 
Admission Reject (ARJ) message, but for purposes of 
illustration, it is assumed that an ACF message is sent). 
In step 606, the calling H.323 terminal sends a Q.931 
Setup message to the called H.323 terminal. In step 
608, the called H.323 terminal sends an ARQ message 
to the gatekeeper 108 which responds with an ACF 
message in step 61 0 (again, a reject message may also 
be provided, rather than an accept message). Once this 
acceptance has issued, an H.245 sequence follows, in 
step 612, in which the calling and called H.323 termi- 
nals communicate with one another concerning the 
common coding algorithm which is to be employed. As 
discussed above, the H.323 terminals must find a com- 
mon algorithm. The H.323 terminals step through their 
hierarchies until one is found. According to the present 
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invention, this determination may be based on use of 
the bandwidth-adjusted new coding hierarchy. It is noted 
that the H.245 sequence may also include bandwidth 
requests and allocations according to the H.323 Rec- 
ommendation. Such standard bandwidth messaging 
may be unaffected by the present invention, except to 
the extent that the individual H.323 terminals base their 
bandwidth requests upon bandwidth requirement deter- 
minations that have resulted after their readjustments in 
response to the BWAS 109. 

[0038] Finally, when the call is terminated, in step 
614, both H.323 terminals send a Disengage Request 
(DRQ) message to the gatekeeper 108. In turn, the 
gatekeeper 108 responds with a Disengage Confirm 
(DCF) message. 

[0039] As discussed above, one aspect of the 
present invention is the renegotiation of codec usage 
while calls are ongoing. FIG. 7 is a flowchart illustrating 
this procedure. In step 702, in a manner similar to that 
described above, the BWAS 109 is provided with the 
bandwidth renegotiation criteria, that is, the criteria or 
thresholds which must be met before the BWAS causes 
renegotiation of codecs. In addition, the BWAS stores 
selection criteria identifying which endpoints have their 
codecs renegotiated as discussed above. 
[0040] Returning to FIG. 7, in step 704. the BWAS 
109 and, particularly, the bandwidth monitor 308 moni- 
tors the condition of the network and, particularly, band- 
width usage. If the criteria for renegotiation of codecs 
are not met, as determined in a step 706, then the proc- 
ess returns to step 704, i.e., monitoring continues. How- 
ever, if one or more of the criteria are met then in step 
708, the BWAS 109 sends one or more control signals 
to the endpoints directing them to renegotiate their 
codecs. As discussed above, this may be a command to 
negotiate lower speed codecs or higher speed codecs. 
In step 710, the endpoints renegotiate their codecs, 
using standard H.323 signaling. The previous codecs 
are then dropped, in step 712. The system then cycles 
back to step 704, i.e., network monitoring, after an 
optional configurable delay (step 714) to prevent the 
possibility of the same connection from being repeat- 
edly downgraded. 

[0041] As discussed above, a number of criteria 
may be used to determine whether a renegotiation of 
codec speeds for one or more existing connections is to 
occur. One method of doing so is similar to the percent- 
data traffic allowed method described above. That is, if 
the amount of data traffic exceeds a predetermined 
threshold, the codec renegotiation process is under- 
taken. 

[0042] Another method, employing QoS levels, is 
described with reference to FIG. 8. In step 800, the 
BWAS 109 saves the requested QoS levels for existing 
calls as well as the actual QoS level being provided. For 
example, the control processor 302 may save this infor- 
mation in the memory 308. In step 802, the BWAS 109 
receives a new call setup request QoS level from an 



H.323 endpoint during call setup. In step 804, the 
BWAS 109 compares the requested QoS level to avail- 
able bandwidth. If the requested bandwidth is available, 
as determined in step 806, then the call is completed in 

5 a step 808. However, if in step 806, it was determined 
that the requested bandwidth was not available, then in 
step 810, the BWAS 109 accesses a database to deter- 
mine whether any existing calls are available which can 
have their bandwidths lowered. For example, if there 

10 exists a current connection having a lower QoS than the 
requested one, the existing connection's QoS may be 
downgraded. Alternatively, if there exist connections 
whose QoS is presently more than needed or 
requested, the connection may be eligible to have its 

75 codec renegotiated. Similarly, various connections may 
be pre-set in a hierarchy identifying whether they can be 
renegotiated. In any case, if no such connections are 
available, as determined in step 812, then in step 816, 
the requested connection is completed at a lower band- 

20 width. If, however, the existing connections may be 
downgraded, the renegotiate lower codec speed proc- 
ess is undertaken in step 814, as described above, and 
the call is made (step 808). 

[0043] As noted above, control and call signaling in 
25 particular embodiments is generally standard H.323 
signaling. However, one implementation of the present 
invention provides additional commands to effect codec 
renegotiation. 

[0044] In particular, with reference to FIG. 9, in step 
30 902, an endpoint Client 1 wants to establish a call to 
another endpoint, Client 2. The endpoint Client 1 sends 
an ARQ message (AdmissionRequest) to the gate- 
keeper GK. The gatekeeper GK responds with an ACF 
(AdmissionConf irm) message to Client 1 , in step 904. 
35 The ACF message includes a Call Signaling Transport 
Channel Address of the gatekeeper GK. In step 906, in 
response to the ACF message, the endpoint Client 1 
sends an H.225.0 setup message to the gatekeeper 
GK, including a Globally Unique Call Identifier to identify 
40 the call. 

[0045] In step 908, the gatekeeper GK relays the 
H.225.0 setup message to the endpoint Client 2. In 
response, in step 910, the endpoint Client 2 conducts 
an ARQ/ACF exchange with the gatekeeper GK. In step 

45 912, the endpoint Client 2's sends H.225.0 Alerting and 
Connect messages to the gatekeeper GK as the call 
progresses to the connect state. The gatekeeper GK, in 
turn provides the Alerting and Connect messages to the 
endpoint Client 1 in step 914. The Alerting or Connect 

so message includes the Gatekeeper H.245 Control Chan- 
nel Transport Address, which is used, in a step 915, to 
establish the H.245 control channel. Next, an H.245 
capability exchange is undertaken, in step 916. In step 
917, the media channel is opened between endpoint 

55 Client 1 and Client 2. 

[0046] Then, in step 918, the BWAS 109 receives 
the QoS information regarding the call that is being 
established. In step 920, the BWAS monitors the condi- 
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tion of the network. In step 922, if the particular change 
codec criteria have been met, then in step 924, the 
BWAS 109 causes the gatekeeper GK to issue a 
ChangeCodecSpeed command to the relevant calling 
party endpoint(s), in this example, endpoint Client 1. 
The ChangeCodecSpeed command includes a "higher" 
or "lower parameter, as appropriate. Then, in step 926, 
the endpoint Client 1 adjusts its codec speed and sends 
a LowerCodecSpeed command (or, if appropriate, a 
HigherCodecSpeed command) to the gatekeeper GK, 
which identifies the existing call whose codec is to be 
renegotiated. In step 928, this command is forwarded to 
the endpoint Client 2. The codec renegotiation then 
takes place over the H.245 control channel, in step 930. 
Once the renegotiation has occurred, the previously- 
used codec(s) are dropped, in step 932, the system 
cycles back to step 920 (after an optional conf igurable 
delay), and the call is made (step 933). If, in step 922, 
the criteria had not been met, the communication would 
have been established without codec renegotiation, in 
step 923. 

[0047] A similar command sequence is used in an 
implementation employing the H.323 direct signaling 
model, as shown in FIG. 10. In step 950, the endpoint 
Client 1 sends an ARQ message to the gatekeeper GK 
requesting that a call to endpoint Client 2 be allowed 
using a direct call model, in step 952, the gatekeeper 
GK responds with an ACF message to the endpoint Cli- 
ent 1. The ACF message includes a Call Signaling 
Transport Channel Address of the endpoint Client 2. In 
step 954, in response to the ACF message, endpoint 
Client 1 sends an H. 225.0 Setup message directly to 
endpoint Client 2. In response to the setup message, in 
step 956, the endpoint Client 2 conducts an ARQ/ACF 
exchange with the gatekeeper GK. Next, in step 958, 
the endpoint Client 2 sends an H.225.0 Connect mes- 
sage to the endpoint Client 1 to progress the call to a 
connect state. In step 960, the endpoint Clients 1 and 2 
exchange H.245 terminal capability messages. In step 
962, the endpoints Client 1 and Client 2 exchange 
H.245 master-slave determination messages and any 
other needed H.245 messages. In step 964, a media 
channel is opened between the endpoints. 
[0048] Alternatively, the exchange of ARQ/ACF 
messages may be omitted. That is, a direct call may be 
established between the endpoints client 1 and 2 with 
no involvement of gatekeeper GK. In this scenario, 
steps 950, 952, and 956 are omitted. That is, in step 
952A, the endpoint Client 1 sends an H.225.0 message 
directly to endpoint Client 2. This causes endpoint Cli- 
ent 2 to process the received H.225.0 Setup message. 
Next, steps 958, 960, 962, and 964 as described above 
are followed. 

[0049] Then, in step 968, the BWAS 109 receives 
the QoS information regarding the call that is being 
established. In step 970, the BWAS monitors the condi- 
tion of the network. In step 972, if the particular change 
codec criteria have been met, then in step 974, the 



BWAS 109 issues a ChangeCodecSpeed command to 
the relevant calling party endpoint(s), in this example, 
endpoint Client 1. The ChangeCodecSpeed command 
includes a "higher" or "lower" parameter, as appropriate. 
5 Then, in step 976, the endpoint Client 1 adjusts its 
codec speed and sends a LowerCodecSpeed com- 
mand (or, if appropriate, a HigherCodecSpeed com- 
mand) directly to the endpoint Client 2. The 
renegotiation then takes place over the H.245 control 
w channel, in step 978. Once the renegotiation has 
occurred, the previously-used codec(s) are dropped, in 
step 980, and the call is made, in step 982, and the sys- 
tem cycles back to monitoring (step 970). If the criteria 
were not met in step 972, then in step 981 , the connec- 
ts tion is made at a lower speed. 

Claims 

1 . A telecommunications system, comprising: 

so 

a packet switched network (101); 
one or more telephony devices (102) coupled 
to said packet switched network, at least one of 
the telephony devices configured to cbrrimuhH 
25 cate using more than one coding algorithms; 

and 

a bandwidth allocation server (104) configured 
to cause a renegotiation of which of said coding 
algorithms said one or more telephony devices 
so (102) communicates with, while said one or 

more telephony devices (1 02) are communicat- 
ing using a predetermined coding algorithm. 

2. A telecommunications system in accordance with 
35 daim 1, said packet switched network (101) being 

H.323 compatible. 

3. A telecommunications system in accordance with 
claim 1 or 2, in which said bandwidth allocation 

40 server (1 04) is configured to initiate said renegotia- 
tion if one or more existing connections have a QoS 
level which may be altered. 

4. A telecommunications system in accordance with 
45 any of the preceding claims, in which said band- 
width allocation server (1 04) is configured to initiate 
said renegotiation if a level of data traffic exceeds a 
predetermined threshold. 

so 5. A method for operating a telecommunication sys- 
tem, comprising: 

monitoring network (101) usage; and 
changing codec (14) speed for one or more 
55 ongoing connections based on said monitoring 

of the network usage. 

6. A method according to claim 5, including determin- 
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ing whether an existing connection has a lower 
quality of service (QoS) requirement than another 
connection, and changing said codec speed for 
said existing connection responsive to a positive 
determination. 5 



7. A method according to claim 5 or 6, including deter- 
mining whether data traffic on said network (101) 
has exceeded a predetermined threshold. 

8. A telecommunications device, comprising: 



10 



means (108) for establishing a communication 
connection with another telecommunications 
device using a first coding algorithm; and 75 
means (109) for changing said communication 
from said first coding algorithm to a second 
coding algorithm. 



9. A telecommunications device according to claim 8, 20 
including means (109) for directing said other tele- 
communications device to renegotiate its coding . ^-,5^^. 
algorithm from said first to said second coding algo- ^ ■/ *\ ^ ~— 

it-.-.~ - . _ • _ c y \ i ; _ 



rithm. .^g: 



10. A telecommunications device according to claim 8 



' - - • v . - . - ... ... ... .......... . . 

or 9, said changing means (109) including means^ 
(306) for monitoring network usage. 

11. A telecommunications device according to claim 30 „ ^ ■ 

10, wherein said monitoring means (306) monitors 
network usage for levels of data traffic. 




12. A telecommunications device according to claim 10 

or 1 1 , wherein said monitoring means (306) moni- 35 
tors network usage for actual and requested quality 
of service (QoS) levels. 

13. A telecommunications device according to claim 

12, wherein said changing means (109) changes 40 
from said first coding algorithm to said second cod- 
ing algorithm if said connection has a lower QoS 
than another connection. 
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